The Internet, which includes a large number of networked computers distributed throughout the world, has become an extremely popular source of virtually all kinds of information. Increasingly sophisticated computers, software, and networking technology have made Internet access relatively straightforward for end users. For example, conventional browser software allows a user to request information or items such as a web page from a network location such as a web site on one or more remote computers. To this end, the user provides the address of the web page (e.g., a uniform resource locator, or “URL”) in some manner to the browser software, and the browser software transmits the request using a communication protocol such as HTTP (HyperText Transport Protocol). The request is then routed to the destination computer or web site based on the address.
When the request is received, the remote web site evaluates the request and returns an appropriate response, which may include the information requested in some formatted content, for example using HTML (HyperText Markup Language). The browser software parses and interprets the returned content to render a page or pages of content on the user's computer display.
When accessed, some web sites attempt to store information on the user's computer, in a small text file referred to as a cookie. Cookies provide for HTTP state management, by which a server may correlate multiple requests coming from the same client. Many times this is desirable to the user, for example, so that the user does not have to repeatedly resubmit information manually to the remote computer hosting the web site, but instead can automatically provide the information as stored in the cookie.
For example, a user can allow cookies to be stored on his or her computer so as to be able to view some web sites, and/or to take advantage of desirable customization features, such as local news and weather, or stock quotes. As can be appreciated, cookies may include sensitive and personal information, or the keystrokes needed to get to a user's sensitive and personal information. For example, a cookie may be used as an authenticator where a cookie may contain a ticket that grants the user access to some restricted resource, such as a personal account at an online brokerage.
Because of the ability to store and exchange sensitive and personal information, Internet security has become a significant concern to individual users, software manufacturers and providers of Internet content.
One way in which Internet security is provided on the client side is via cross domain access rules, which generally ensure that for any received content, that content can only interact with content from the same web domain. For example, a typical page on www.1a2b.com can freely script content on any other page on www.1a2b.com, but cannot script to pages that are located on a different web domain. An enforcement mechanism ensures that only pages with identical domain properties are allowed to freely interact on the client side.
A relatively recent but common security problem is cross-site scripting. Cross-site scripting is a server-side vulnerability that enables malicious script (e.g., written by a hacker) to execute on a client machine. Such vulnerability allows an attacker to inject a piece of script (e.g., JavaScript) into a web page produced by a trusted web server. A browser executes the injected script as if it were provided by the server. Since the security restrictions of a browser are based on the origin of the web page, the script is executed by the browser under the same permission as the domain of the web application, by-passing the security restrictions.
For example, consider a web site that, after a user logs in, redirects the user to a welcome page that returns content based on information passed in the URL (e.g., www.1a2b.com/defaultasp?name=username) that when rendered at the client, greets the user by the username that was provided. However, if a script instead of the username is provided, vulnerable servers will pass back the script, and when the welcome page is rendered, the script will be executed on the client side. Thus, if a hacker tricks the user into clicking on a link to that site with a malicious script (instead of the username) sent to the server, such as www.1a2b.com/default.asp?name=<script>evilScript( )/script>, the web site passes back the script embedded into its content, as if it was the username.
When the browser interprets this part of the content as script, the browser automatically runs the script, which is normal browser behavior. However, because the script came from the web site, the script is able to instruct the browser to perform operations in that site's domain, including sending that site's cookie or cookies to another computer, such as the hacker's computer. In this manner, cross site-scripting can steal cookies, and thus a hacker can obtain a user's sensitive information. The problem is difficult to detect at both clients and servers, since servers often return content based on information passed with a URL, and clients often run scripts returned from a server.
Current web browser security models allow script executing on a web page to make HTTP (HyperText Transport Protocol) requests to interact with other HTTP resources on the same domain. If some of these resources require cookie-based authentication, it is possible for someone to stage a cross-site scripting attack to gain access to a victim's data as long as both resources are on the same domain.
One solution to the problem of cross-site scripting attacks includes generating a new publicly-accessible time-expiring URL (uniform resource locator) for each resource whenever it is needed instead of using cookies for authentication. However, this solution enables the URL to be given to unauthorized parties, who then have temporary access to the resource before the URL expires. Another solution involves using a different domain for every resource owner. For example, a script on alice.server.com cannot communicate with bob.server.com. But here too, the cross-site scripting attack problem can still exist when multiple resources within the same subdomain have different access control lists. And using a different domain for every resource suffers from being overly restrictive—no script is able to make HTTP requests to other resources, even when desired.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.